In a conventional second generation mobile communication network, each geographical cell of the network is served by a Base Station Transceiver (BST) which provides the network side of the air interface. A set of BSTs are physically connected to a Base Station Controller (BSC) which is in charge of the allocation of radio resources to subscribers. Each BSC is in turn physically connected to a Mobile Switching Center which is responsible for the routing of incoming and outgoing calls to the mobile network and is responsible, in particular, for handling the mobility of subscriber devices. In the case of a 3G network, so-called Node B's are broadly equivalent to the BSTs of the 2G network, whilst the Radio Network Controller (RNC) takes the place of the BSCs. Both 2G and 3G networks may comprise packet-switched core networks in addition to the circuit-switched core network. In the packet-switched network architecture, the MSC is replaced by the Serving GPRS Support Node (SGSN).
Traditionally, vertically integrated networks have been built to deliver single services such as telephony or data access. FIG. 1 illustrates this vertically integrated architecture in the case of a 2G network. However, in order to increase the “modularity” of network components and therefore reduce network construction and operating costs, a solution sometimes known as the Mobile Softswitch Solution (MSS) architecture has been introduced. This architecture is described in an Internet published whitepaper titled “Efficient Softswitching”, Ericsson A B, August 2006, which can be found at: http://www.ericsson.com/technology/whitepapers/8107_efficient_softswitching_a.pdf. Softswitching in combination with IP technology allows for a layered architecture approach according to which service execution, control and connectivity can be horizontally integrated across multiple access networks. Softswitches separate the call control and switching functions into different nodes, consequently separating control and connectivity layers.
As a particular example, the conventional MSC is split in the layered softswitch architecture into an MSC Server (MSC-S) which handles the control plane signalling and a Mobile Media Gateway (M-MGW) which handles user plane traffic. A Gateway Control Protocol (GCP) is used between the MSC-S and the M-MGW in order to allow the MSC to control user plane bearers. All GCP signalling messages are transported between the M-MGW and the MSC-S using a long-lived Stream Control Transmission Protocol (SCTP) association established between the two entities. Although the M-MGW does not make use of the control plane signalling as such, this signalling is relayed by the M-MGW en route from the BSC/RNC to the MSC-S. More particularly, it is possible to transport this signalling over a second SCTP association established between the M-MGW and the MSC-S.
In today's advanced MSS networks, server pooling is the standardised concept to achieve geographical redundancy in the networks. This avoids inter alia the failure of a single server from resulting in a failure of the network to provide services to subscribers. A generalised MSS server pooling architecture is illustrated in FIG. 2. In the case of an MSC-S pool, it will be appreciated that if one MSC-S fails, BSCs/RNCs currently allocated to that MSC-S can be reallocated. In a pooled architecture, an MSC Pool Proxy can be introduced between the BSC/RNC and a pool of MSC-S in order to support BSCs/RNCs that do not support MSC-S pooling. This Pool Proxy acts as a single point of contact for BSCs/RNCs to the MSC-S pool. In more general terms a pool proxy is used to connect network nodes to pool nodes. Such pool nodes can be pool servers. Whilst the MSC Pool Proxy can be a standalone node, it is preferable to integrate this functionality into the M-MGW in order to save on operating costs.
The pooled approach to the provision of network nodes provides security against failure of an individual pooled node. However, a pool proxy itself constitutes an architectural element that is a critical point of failure. It is therefore desirable to introduce pool proxy redundancy into the architecture, for example as illustrated in FIG. 3 for the case of an MSC-S pool. One approach to this involves configuring each BSC/RNC to be able to independently address two (or more) pool proxies, where in this example the pool proxies are located at respective M-MGWs.
A BSC or RNC may be unaware of the presence of the pool proxy, with the BSC or RNC merely addressing the proxy using the Signalling Point Code (SPC) as if the proxy were a regular MSC. Such a BSC or RNC cannot separately address a plurality of pool proxies (or MSCs as the BSCs or RNCs see them).
A problem to be addressed therefore is how to introduce pool proxy redundancy into a network without giving rise to conflicting signalling on the interface between the pool proxies and the BSCs/RNCs or other network nodes.